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1. (U) Introduction 

(U//FOUO) The purpose of this document is to introduce and explain the TAO Data Item 
Wrapper (TDIW) Schema. The TAO Data Item Wrapper reflects TAO’s efforts to 
support NSA Data Tagging Initiatives. 

(U//FOUO) The TDIW is being defined and maintained by the Mission Management 
Engineering Division (MMED). It is being used by TAO and TD systems. 

2. (U) Document Navigation 

(U//FOUO) The sections of this document provide the following information: 

A. Purpose: high level summary of reason TDIW exists 

B. Background: a brief history of efforts that led to development of TDIW 

C. General Overview: high level overview of content of the TDIW 

D. Detailed Overview: greater explanation of TDIW plus implementation guidance 
to developers 

2. 1 (U) Purpose 

(C//REL TO USA, FYEY) Purpose of the TAO Data Item Wrapper is: 

• To support TAO FISA remediation efforts by explicitly documenting 
Authorization and age-off information. 

• To enable SID Authorization Compliance efforts. 

• To enable TAO data consumers to implement proper access control mechanisms, 
by properly marking data with Classification, SCI Control, Dissemination 
Control, and additional access control enabling markings. 

• To enable sharing of TAO obtained and produced information by segmenting 
information and marking each segment with its own Classification, SCI Control 
and Dissemination Control markings. 

• To enable SID SIGINT Value Assessment efforts. 

• To support NSA’s Mission Management - Mission Advisory Group (MM-MAG) 
Data Tagging Vector. 

• To support NSA’s Data Provenance efforts. 

2.2 (U) Background 

(U//FOUO) In December 2007, TAO reviewed the SID authored End-to-End Data 
Tagging Capability Concept of Operations. In March 2008 TAO reviewed the SID 
authored End-to-End Data Tracking Tags Capability Requirements Document. TAO has 
been actively engaged with the SID Data Tagging efforts ever since. 

(U//FOUO) Deficiencies in the quantity and quality of the metadata exchanged between 
TAO and the organizations that consume TAO acquired data had become an obstruction 
rather than the occasional nuisance. 
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(U//FOUO) In October 2008, TAO began working with TE Mission Systems Engineering 
(TE2) to enhance an existing TAO Data Header. 

(U//FOUO) The legacy header that TAO has been applying to data being pushed to 
corporate consumers is based on CCDF Traffic Version 2.5. 1 DTD. It is referred to 
within MMED as the “CCDF Header”. The DTD that this header is based upon no 
longer exists on NSAnet and it is no longer supported by TE2, the authors of CCDM and 
CCDF. The CCDF-based header does provide the capability to document Classification, 
SCI Control and Dissemination Control markings. It does not enable TAO to document 
FISA related information. The CCDF-based header is the equivalent of page marking a 
document. 

(U//FOUO) MMED has authored an update to the CCDF-based header. The enhanced 
header has been named the “TAO Data Item Wrapper” (TDIW). The TDIW draws 
heavily from the current set of CCDM models. Because TAO needed to document 
information for which a model does not currently exist in CCDM, the TDIW does not 
conform 100% to CCDM. MMED has coordinated the TDIW development with TE2 
and received their verbal approval to proceed. The TDIW is the equivalent of page 
marking *and* portion marking a document. 

2.3 (U//FOUO) General Overview 

2.3.1 (U) Key Components 

(U//FOUO) This version of the TDIW XMF Schema Definition (XSD) is made up of the 
following key components: 

• Data Item Wrapper XSD version 2.3 

• Enterprise Security Model version 1.2 XML Schema files 

• Activity Authorization Model XSD version 1.2 

• Excerpts from Cryptologic Common Data Model (CCDM) XSD v4.5.2 

• Oim_types XSD vl.O 



Figure 1. TDIW Components / Overview 
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(U//FOUO) The TDIW is intended to accompany data that is transferred from system to 
system. 

(U//FOUO) The TDIW XSD defines four segments of information: 

• Root 

• Mission 

• Device 

• Dataltem 

(U) Each section of the header is individually classified. The root level document is 
classified to reflect the most restrictive aggregate of all the multiple sections. 

Developer Guidance: For the purposes of TAO data, the disseminationControls shall 
always contain either REL or NF (in addition to any other allowed dissemination 
controls). If REL is present, the releasableTo attribute must contain USA and at least one 
of the other allowed trigraphs or tetragraphs. If NF is present, the releasableTo attribute 
should not be present. 

Rationale: We want to explicitly mark whether information is releasable or not, and we 
don't want to potentially confuse users by having a null value attribute present. 

(U//FOUO) One or more data items may be documented in the TDIW, one each per 
Dataltem segment. The TDIW schema allows wrappers to have unbounded number of 
devices and dataitems. Currently, there is no way to tie which dataitem(s) go with which 
device(s). This is a known deficiency of the TDIW. It assumes all data items are 
acquired from the same device during the same mission. There are no immediate plans to 
address this with the TDIW as it will become obsolete by the Enterprise Data Header. 


(U//FOUO) The “DataltemWrapper” root element documents the name spaces in use 
for this version of the TDIW, the date an instance of the TDIW was created, and 
identifies the version of the schema an instance of the TDIW conforms to. 

(U//FOUO) The “Mission” element documents information about the intelligence 
activities that produced the data item: who performed them, under what authority, in 
response to what tasking request, relevant to what SIGINT priority. 

(U//FOUO) The “Device” element documents information about the device that was 
targeted: key identifiers and select information to aid processing of the acquired data 
item. 

(U//FOUO) The “Dataltem” element documents information about one payload(s) that 
was acquired from the identified Device. Multiple Dataltem elements can be used within 
a single TDIW to describe multiple data items acquired from the same Device during the 
same activity. 

(U//FOUO) The segmentation of the data contained wi thi n the TAO Data Item Wrapper 
creates some opportunities as well as some challenges for TAO data consumers. It 
enables consumers to glean information from the TDIW and know how to provide access 
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controls to the extracted information. However, most consumers are only prepared to 
handle metadata contained in a single file that has only document- level markings. They 
are not prepared for a single document that contains multiple sections, each of which has 
their own portion-markings. 

(U//FOUO) The TAO Data Item Wrapper does *not* introduce any new data aggregation 
classification challenges. It does ^surface* issues that have always existed and will need 
to be addressed. Specifically, as more metadata is included with data, the markings of the 
entire file become more restrictive, often becoming NOFORN, and at times ECI. The 
aggregation of metadata still needs to be properly marked. The TE Security model 
allows each element and attribute of the TDIW to be portion marked, however, we 
choose not to do this for the TDIW. The TDIW segmentation was a compromise 
between document-only markings and element/attribute-markings. In the absence of a 
classification guide, or portion marks that specify otherwise, we have to manually define 
the rules for how segments will be classified. The segmentation of the metadata within 
the TAO Data Item Wrapper has enabled TAO to more precisely mark its data and use 
corporate tools to apply marking aggregation rules. 


2.3.2(11) Enterprise Data Header Compliance 

(U//FOUO) MMED mapped the elements and attributes of TDIW version 2.3 to the 
specification for the Enterprise Data Header (EDH) version 1.0 Basic mode, and provided 
that mapping to TE2 for review. TE2 reviewed the mapping and responded: "We have 
evaluated the data which you furnished in the spreadsheet of TDIW 2.3. With the 
exception of the Selector and Selector UUID, the data tags indicated wi thi n the 
spreadsheet, if properly developed and handled, are compliant with the EDH 1.0. The 
suggested replacement for the Selector and Selector UUID appear to satisfy the command 
control quality and trace back requirements. The values are understood to be Security 1.2 
and it is expected that there will be forward change to Enterprise Security Model (ESM) 
1.3 and eventually ESM 1.4 (adds AuthID)." 

(U//FOUO) The TDIW-EDH mapping can be located at 
http://www.sigint.nsa/sublevell/si3/si32/si325/index.html . 
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2.4 (U//FOUO) Detailed Overview 

(U//FOUO) The “Developer Guidance” is directed towards those persons that are using 
the TDIW to wrap acquired data. 

2.4.1 (U//FOUO) The Root 

(C//REL) The TDIW Root level, “DataltemWrapper”: 

• Specifies the namespace declaration for the TDIW, 

• Specifies the Enterprise Security model namespace, 

• Specifies the Activity Authorization model namespace, 

• Documents the date and time an instance of the TDIW is generated, 

• Documents the version of the TDIW XSD an instance of the TDIW conforms to. 

• The “CreationDate” element documents the date and time that this instance of 
the data item wrapper was created. The “CreationDate” is the local time at 
the location generating the TDIW expressed in GMT (Zulu) time. No offset is 
permitted even though it is allowed by the xs:DateTime type.” 

Example: A TDIW was created at NSAW on March 14, 201 1 at 10:38 Eastern 
Time w/Daylight Savings in effect (EDT). The resulting TDIW’s CreationDate 
should be: 

<CreationDate>2011-03-14T14:38:28.259Z</CreationDate> 

This element is not the date that the data item was acquired. The 
“CreatedDateTime” element within the Dataltem section documents the 
acquisition time reference. If the same TAO acquired raw data file was re-sent 
through the TAO Data Marking process, each instance of the TDIW would have 
a different “CreationDate”. However, both would contain the same value in the 
“CreatedDateTime” element. 

■ Developer Guidance: Mandatory. Populate with date and time that the 
TDIW is generated. 

■ Rationale: Can be used to determine data processing latency. Can be 
used to identify retransmitted data. 

• The attribute name “schema Version” specifies the schema version of the TDIW 
to pass on to the xml document. 

■ Developer Guidance: Mandatory 

■ Rationale: enable data consumers to identify version of XSD to use 
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2.4.2 (U//FOUO) Segment 1- Mission 

2.4.2. 1 (U//FOUO) “Mission” 

(U//FOUO) The “Mission” element documents information about an activity and the 
requirement the activity addresses. 

■ Developer Guidance: Mandatory 

■ Rationale: Significant FISA compliance-enabling information is documented in this 
segment. 

2.4.2.2 (U) “Requirement” 

(U//FOUO) The “Requirement” element references a requirement type that documents 
the National Intelligence Priority Framework (NIPF) Topics and Geopolitical Entities 
that this object may be relevant to. NIPF is SID’s benchmark for SIGINT Value 
Assessment Efforts. 


The element field is “NIPFTopicGeoPair” and contains two sub-elements: the 
“Topic which documents the valid NIPF topic value and the “GeopoliticalEntity” which 
documents the valid NIPF Entity. Documenting this information will enable TAO to 
associate the activity performed by TAO, and hence the acquired data item(s) to NIPF 
Topics and Geopolitical Entities. This association will enable NSA Data Tracking and 
SIGINT Value Assessment efforts. 

■ Developer Guidance: DO NOT POPUFATE at this point in time. 

■ Rationale: MMED encountered classification challenges with the Geopolitical entity 
values. According to the NIPF Classification Guide, the identities of some NIPF 
state and non-state actors are NOFORN. A listing of a subset of state and non-state 
actors is NOFORN. Since MMED does not have the rules to programmatically 
know which individuals or what sets are considered NOFORN, we would have to 
default this information and hence the entirety of the Mission segment as NOFORN. 
MMED is working with Sll to have Sll provide a unique, immutable cell 
identification or reference id capability for the NIPF matrix. Such a reference ID 
would be (U//FOUO) at the most. 

2.4.2.3 (U) “Activity” 

(U//FOUO) The “Activity” element documents information about an activity performed 
by some SIGINT resource. It enables TAO to document information about: 

• the activity that was performed by TAO 

• the tasking that caused the activity to be performed 

• the authorization that authorized TAO to perform the activity such as: United 
States Foreign Intelligence Surveillance Court order, the Attorney General 
certification, or Executive Order 12333 

• the TAO asset that performed the activity 

• the start and stop, date and time, or the duration of the activity 
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(U) Multiple activities may be authorized by the same authorization and multiple 
authorizations may authorize the same activity. However, the activity element will list 
only one explicit authority for the data item described in the “Dataltem” segment. 

■ Developer Guidance: Mandatory 

■ Rationale: TAO has decided it will explicitly document the authorization under 
which it performs the activity that acquired the data. 


2A.2.4 (U) “Activity Authorization” 

(U) “Activity Authorization” documents facts about the authorizing in strument or record 
giving official permission for or approval to perform certain activities. It is that part of an 
authorization that is the legal basis for a specific type of mission activity. This element is 
further defined by the sub-elements below. 

■ Developer Guidance: Mandatory. 

1 . Must document the authorization for the collect activity that acquired the data. 

2. Must document the authorization for the retain activity. 

■ Rationale: To enable proper access control, age-off and data retention mechanisms. 

(U//FOUO) “Authorization” 

(U) The “authorization” element is the 'composedOf “Reference” and “Sponsor”. 

(U) “Reference” 

The element "Reference" is a word or phrase that identifies or serves as a citation for an 
authorization. The attribute name "scheme" is a particular ordered system or arrangement 
within which the word or phrase identifying the Reference is unique. It may be, for 
example, the name of a database or a reference to a numbering system such as "FISC 
Docket Number". 

■ Developer Guidance: Mandatory 

■ Rationale: explicitly document the identifier of the authorizing instrument 
(U) “Sponsor” 

(U) The 'sponsor' element is implemented using the identifier of the sponsor, the name or 
number by which an organization is known. 

■ Developer Guidance: Optional 

■ Rationale: If known populate it. 

(U//FOUO) “DataHandlingRequirement” 

(U//FOUO) The element "DataHandlingRequirement" documents information related 
to compulsory control or management of information acquired under the authorization. 
The “Data Handling Requirement” contains a data label which specifies a word, or 
words, indicating the sensitivity of the information or the criteria that must be met for 
access to the information. Values for the “data label type” are documented in the 
activity Authorization.xsd. 
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■ Developer Guidance: At least one DataHandlingRequirement element is required. 
The value for the required “DataHandlingRequirement” element shall be, 
“legalAuthorityFramework” = RAWSIGINT. 

■ Rationale: Supports Policy 1-56. The data TAO currently acquires is done so under 
the SIGINT Mission Authority Framework. 

■ Developer Guidance: When the authorization is not EO 12333, an additional 
“DataHandlingRequirement” element is required. The values for this 
“DataHandlingRequirement” element shall be (type = “fisa”) and the value shall 
match the Authorization type. This information will be obtained from the Security 
Marking Service. 

■ Rationale: This is the mechanism used in the Authorization Model to document the 
training required to access data acquired by this type of FISA. 

(U) “AuthorizedActivity” 

(U) The element "AuthorizedActivity" documents the activity that was authorized via 
the referenced Authorization. 

■ Developer Guidance: Document one ActivityAuthorization element for the 
‘collect’ AuthorizedActivity. Document a separate ActivityAuthorization element 
for the ‘retain’ AuthorizedActivity. 

■ Rationale: explicitly associate temporal information with each activity. 

Version 2.3 of the TDIW does allow the value of “indefinite” for “retain”. This is a bug. 
Based on guidance from TAO/R&T and TAO Compliance personnel, 5 years is the 
default retention value for E012333 collect. Therefore, the values should not be listed as 
"indefinite” and will change is subsequent versions. The retain rule will be changed in the 
Mission Management Application (MMA) and underlying data store so that the Security 
Marking Service (SMS) returns the correct values. TURBINE is currently using the 5 
year value for its default value. Collection activity with "indefinite" expiration will be 
allowed because E012333 does not have an expiration date. 

(U) “BeginDateTime” 

(U) The "BeginDateTime" element defines the date and time when the specified 
AuthorizedActivity is allowed to start. 

■ Developer Guidance: see guidance provided below in 'Activity Temporal Values' 


(U) “ExpirationDateTime” 

(U) The elements "ExpirationDateTime" and “Expiration Value” are used to document 
when the specified AuthorizedActivity must stop. "ExpirationDateTime" is used to 
document the day, month, year, hour, and mi nute when the specified AuthorizedActivity 
must stop. “ExpirationValue” is used to document the fact that no explicit stop date and 
time has been specified for the AuthorizedActivity. In essence the AuthorizedActivity 
may continue indefinitely. 

■ Developer Guidance: see guidance provided below in 'Activity Temporal Values' 
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(U) “Duration” 

(U) The element name "Duration" indicates a length of time, relative to the occurrence 
of some significant event, during which an AuthorizedActivity is allowed to be 
performed. For example, the "retain" activity could be authorized for some number of 
months following an "acquisition" event. The attribute "startingEventTypeEnum" 
documents the event from which point the duration shall be calculated. 

■ Developer Guidance: see guidance provided below in 'Activity Temporal Values' 

(U) “Activity Temporal Values” 

■ Developer Guidance: For the ‘collect’, AuthorizedActivity “BeginDateTime” is 
Mandatory. 

■ Rationale: Explicitly document when the collection activity was authorized to begin. 
Can be used to determine over-collect incidents. 

■ Developer Guidance: For the ‘collect’ AuthorizedActivity, one of either 
“ExpirationDateTime” or “Expiration Value” is Mandatory. 

■ Rationale: Explicitly document when the collection activity was required to stop, if 
at all. Can be used to determine over-collect incidents 

■ Developer Guidance: For the ‘retain AuthorizedActivity, one of either 
“ExpirationDateTime” or “Duration” is Mandatory. 

■ Rationale: Explicitly document when the collection activity was required to stop, or 
how long it was allowed to continue. Can be used to make age-off and retention 
decisions. 


2A.2.5 (U) “TaskRequestldentifier” 

(U//FOUO) The “TaskRequestldentifier” element documents the identifier of the task 
request that triggered the documented Activity. The “originator” attribute is used to 
document an identifier of the system from which the tasking originated. 


(U//FOUO) “TaskRequestName” 

The “TaskRequestName” element is the name of the task request. 


(U//FOUO) “TaskRequestStatus” 

The “TaskRequestStatus” references “TaskRequestStatusEnum” and describes the 
status of the high level mission task issued by an analyst or system such as 
TUNINGFORK. The allowable values are as follows: “Pending”, “Submitted”, 
“Completed”, “Failed”, “Cancelled”, and “Unknown”. 

■ Developer Guidance: see guidance provided below in 'Task Request Information' 
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(U) “Task Request Information” 

(U//FOUO) The “TaskRequest (*)” information is intended to enable systems such as 
TUNINGFORK to associate acquired data to the task requests they issued. 

■ Developer Guidance: Optional. Populate if information is known 

■ Rationale: This information will enable Purge Surge Compliance efforts by 
indirectly identifying the selection methodology used to acquire the data items. 



Figure 2. Task Status Overview 


2A.2.6 (U) “Pddg” 

(U) The “Pddg” is the Position Digraph Designator for the system that acquired the data 
items 

■ Developer Guidance: Mandatory 

■ Rationale: Supports Purge Surge Compliance requirements to identify source of 
acquired data. 

2A.2.7 (U) “CollSigad” 

(U//FOUO) The “CollSigad” is the SIGINT address for the system that acquired the data 
items 

■ Developer Guidance: Mandatory 

■ Rationale: Supports Purge Surge Compliance requirements to identify source of 
acquired data. 
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2.4.2.8 (U//FOUO) “Agent” 

(U//FOUO) The “Agent” element documents information about the Agent that 
performed the activity that acquired the data items. For TAO, Agent is usually an 
Implant. Sub-elements include: 

(U//FOUO) “Agentldentifier” 

(U//FOUO) This element documents the unique identifier of the person or software that 
performed the activity. 

■ Developer Guidance: Mandatory if known. 

■ Rationale: This information will enable Purge Surge Compliance efforts by 
identifying the entity that acquired the data items. 

(U//FOUO) “AgentName” 

(U//FOUO) "AgentName" documents the name of the person or software that performed 
the activity. 

■ Developer Guidance: Mandatory if known. 

■ Rationale: This information will enable Purge Surge Compliance efforts by 
identifying the entity that acquired the data items. Will also enable data flow metrics 
generation. 

(U//FOUO) “AgentType” 

(U//FOUO) "AgentType" documents the family of software the agent that performed the 
activity belongs to. 

■ Developer Guidance: Mandatory if known. In some cases, may be the same value as 
documented in “AgentName”. 

■ Rationale: This information will enable Purge Surge Compliance efforts by 
identifying the entity that acquired the data items. Will also enable data flow metrics 
generation. 

(U) “Version” 

(U) "Version" documents the version of the software that performed the activity. 

■ Developer Guidance: Optional. If the Agent is software, Populate if information is 
known. 

■ Rationale: Will enable root cause analysis and metrics generation efforts 

(U) “Patch” 

(U) "Patch" documents the patch designator of the software that performed the activity. 

■ Developer Guidance: Optional. If the Agent is software, Populate if information is 
known. 

■ Rationale: Will enable root cause analysis and metrics generation efforts 
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2.4.3 (U//FOUO) Segment 2- Device 

(U//FOUO) The “Device” element documents information about a device from which the 
information was acquired. The device could be an asset or a target. The information 
documented includes any identifiers, such as COVERTERMS, UUIDs, case notations, 
addresses. It can document the fact that the device has been afforded protection from 
targeting by a particular policy. The “Device” section includes the sub-elements: 

2.4.3. 1 (U) “Role” 

(U) The “role” element currently documents if an object is being targeted or not. 

■ Developer Guidance: Mandatory. 

■ Rationale: Explicitly identify if the device, from which the data item was acquired, 
is a SIGINT target or not. This can be used to help the SIGINT system distinguish 
among raw SIGINT acquired from a targeted device, vice mission management 
information produced by a SIGINT device. 

2.4.3. 2 (U) “Devicename” 

(U//FOUO) The “Devicename” element provides the name of the device from which the 
data item was acquired. 

■ Developer Guidance: Mandatory. 

■ Rationale: Explicitly identify the device, from which the data item was acquired. If 
the device is a SIGINT target, this information will enable Purge Surge Compliance 
efforts. If the device is a SIGINT target, this element is called the project name in 
the Security Marking Service. 


2.4.3. 3 (U//FOUO) “CaseNot” (Case Notation) 

(S//SI//REL FVEY) The “CaseNot” element describes the casenotation of the device 
being targeted. The element includes two attributes, “version” and “scheme”, which are 
used to identify the Case Notation schema that the “Casenot” conforms to. 

■ Developer Guidance: Mandatory if Known. 

■ Rationale: Explicitly identify the device, from which the data item was acquired. For 
TAO, this references the TAO Case Notation Spec. This information will enable 
Purge Surge Compliance efforts to identify the source of the acquired data. 

2.4.3. 4 (U) “Deviceidentifier” 

(U//FOUO) The “Deviceidentifier” element defines the identifier of the device being 
tasked. The “state” attribute is used to enable TAO to document if this device was ever 
known by any previous identifiers. Although not desired, it is possible for multiple target 
ids to be assigned to the same device. Therefore, the best we can do in the event that 
occurs and is subsequently discovered, is document the fact that a device is currently 
identified with the “active” id, and has previously been identified with the “previous” 
id. 
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■ Developer Guidance: Mandatory if known. Use the “state” attribute to indicate if the 
Identifier is the current identifier or if it is a previous identifier. 

■ Rationale: Explicitly identify the device, from which the data item was acquired. If 
the device is a SIGINT target, this information will enable Purge Surge Compliance 
efforts. 

2.4.3. 5 (U) “IsProtected” 

(U) The “IsProtected” documents the fact that the device being described is afforded 
protection from being targeted according to a specified protection policy. 

■ Developer Guidance: Mandatory. When the ‘collect’ AuthorizedActivity is 
authorized under EO 12333, the “IsProtected” element should be set to false. When 
the ‘collect’ AuthorizedActivity is authorized under any other Authorization the 
element should be set to true. 

■ Rationale: Explicitly document that, at the time the data was acquired, the device 
being targeted either was or was not afforded protection by US Policy. 

2.4.3. 6 (U) “ProtectionPolicy” 

(U) The “ProtectionPolicy” is used in conjunction with the “IsProtected” element to 
identify the policy under which the Device is afforded protection from being targeted. 

■ Developer Guidance: If the authorization is NOT E012333, the “ProtectionPolicy” 
element must be present and the value set to “USSID SP00018”. 

■ Rationale: Explicitly identify the Policy that defined the conditions under which 
protection from targeting would be required. 

2.4.3. 7 (U) “HostName” 

(U) The “HostName” element documents the name applied to the device by the device 
ad mi nistrator 

■ Developer Guidance: Mandatory if known 

■ Rationale: Aids downstream analysis. 

2.4.3. 8 (U) “FullyQualifiedDomainName” 

(U) This element documents the fully-qualified domain name of the device. 

■ Developer Guidance: Mandatory if known 

■ Rationale: Aids downstream analysis. 

2.4.3. 9 (U) “Region” 

(U) The “Region” element documents the location in the world the Device is believed to 
be located in. The values contained in this element are in accordance with the ISO-3166 
standard. 

■ Developer Guidance: Mandatory if known 

■ Rationale: Aids downstream analysis and USSID SP001 8 concern determinations 

2.4.3.10 (U) “MacAddress” 

(U) The Medium Access Control (MAC) address of the device 

■ Developer Guidance: Mandatory if known 
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■ Rationale: Aids downstream analysis. 

2.4.3.11 (U) “OperatingSystemlnstalled” 

(U) Defines the type of operating system installed on the device. 

■ Developer Guidance: Mandatory if known 

■ Rationale: Enables downstream systems to process the data items properly. 
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2.4.4 (U//FOUO) Segment 3 - Data Item 

(U//FOUO) The “Dataltem” element documents information about the data item 
acquired from the Device. The data item could be acquired from a target Device or 
produced internally by a non-target Device such as a SIGINT command and control 
system. The “Dataltem” element documents information about the acquired data item 
both information created by the SIGINT system and information acquired by the SIGINT 
system. The “Dataltem” section includes the sub-elements: 

2.4.4. 1 (U) “DataltemType” 

(U//FOUO) The “DataltemType” element, documents the acquired data item’s Payload 
type. 

■ Developer Guidance: Mandatory if known 

■ Rationale: CES requested the addition of an indicator of the Payload Type in the 
Data Item section. 

2.4.4.2 (U) “Dataltemldentifier” 

(U) The data item designator value is a unique identification number. 

■ Developer Guidance: Mandatory 

■ Rationale: Mandatory field for Purge Surge Compliance. Also enables Data 
Provenance efforts. 

2.4.4.3 (U) “CreatedDateTime” 

(C//REL FYEY) The “CreatedDateTime” element documents the date and time the data 
item was acquired from the Target environment. TAO shall use the Date and Time the 
data was acquired to the TAO classified network (high side), as the Date/Time of 
Acquisition (DTOA). Providing accurate and consistent DTOA at locations prior to the 
TAO classified network is either impractical for technical reasons or undesirable for 
OPSEC reasons. The Date/Time of Acquisition will be documented in the 
“CreatedDateTime”. 

(C//REL FVEY) The element name "CreatedDateTime" was provided to TAO by TE, 
and is used in the Enterprise Data Header (EDH). TE chose to use 
“CreatedDateTime” vice DTOI or DTOA because “CreatedDateTime” is more 
corporately applicable. This enables NSA to mark every data item with an NSA 
“CreatedDateTime”, whether those data items were acquired from the target 
environment or produced internal to NSA. The TE2 definition for “CreatedDateTime” 
is "The date / time to second precision that the data item entered into the control of the 
SIGINT enterprise." 

■ Developer Guidance: Mandatory 

■ Rationale: Mandatory field for Purge Surge Compliance. Also enables data age-off 
and retention decisions. 
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2.4 .4.4 (U) Expiration 

(U//FOUO) “Expiration” is the date and time when authority to retain the data item 
expires and is based on “CreatedDateTime” and the expiration or duration information 
specified by the authorization under which the data item was acquired. 

■ Developer Guidance: Mandatory. If the ‘retain’ AuthorizedActivity has a 
documented “ExpirationDateTime”, then the “Expiration” element gets populated 
with the “ExpirationDateTime” value. If the ‘retain’ AuthorizedActivity has a 
documented “Duration” then the “Expiration” element gets populated with the 
(“CreatedDateTime” value added to the “Duration” value) 

■ Rationale: Enables Purge Surge Compliance. Also enables data age-off and retention 
decisions. 

2.4A.5 (U//FOUO) File 

(U//FOUO) The “File” element provides amplifying information for the acquired data 
item, as known by the device from which the data item was acquired. If the information is 
known or available it should be provided. The data elements are from the perspective of 
the source device. 

I. (U) “Access” - The date and time that the file was last opened. The attribution 
type is a date time format like the example listed below. 

EXAMPLE: 2000-0 1-01 TO 1: 35Z. 

II. (U) “BlockCnt”- Block count is the number of data units a file takes on a 
storage device. This information is based on ANSI Tl. 523-2001 Telecom 
Glossary, American National Standards Institute, New York, New York, 2001. 
The value for this element is an integer. 

III. (U) “Create” - Create is the date and time that the file was produced. 

IV. (U) “Extension” - The file extension is used to imply the computer file type. 
The value in this component must not include either the file path or the file 
name. The file extension is usually specified as a suffix to the filename 
preceded by a decimal Where multiple decimals appear in the full name 
the last is usually taken as the marker for the beginning of the file extension. 
This is OS dependent however. For example, in the following Windows 
example "C:\My PathVFolder l\Folder 2\TheFile.txt", only "txt" should appear 
in this attribute. 

Y. (U) “Filename” - A non-empty string that is used to identify a computer file. 
The value in this component must not include either the file path or the file 
extension. For example, in the following Windows example "C:\My PathVFolder 
lVFolder 2\TheFile.txt", only "TheFile" should appear in this attribute. 

VI. (U) “Modify” - Date and time that the file was last revised. EXAMPLE: 2000- 
01-01T01: 35Z. 

VII. (U) “Pathname” - A description of where an item is to be found in a hierarchy 
of file directories. The value in this component must not include either the file 
name or the file extension. For example, in the following Windows example 
"C:\My PathVFolder lVFolder 2VTheFile.txt", only "C:VMy PathVFolder lVFolder 
2" should appear in this attribute. 
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VIII. (U//FOUO) “Size” - The size of an attachment as extracted from acquired data. 
Size values are not normalised; that is, there is no requirement to convert to a 
particular measure of size. 

IX. (U) “Groupname” - Name or pneumonic associated with a Group. A group is a 
set of consenting users. The group name is assigned by a system administrator. 
EXAMPLE: devdni 

X. (U) “Ownername” - Name of the owner of a computer system resource. 
EXAMPLE: Bob. 

XI. (U) “Groupld” - The unique designator assigned to a collection of UNIX 
operating system users who have protected access to their resources. 

XII. (U) “Ownerld” - The unique designator assigned to the owner of a file in a 
UNIX operating system. 

■ Developer Guidance: Optional. Provide if known. 

2.4.4. 6 (U) Locator 

(U//FOUO) This element documents the reference to the location of the acquired data 
item. The attribute “mechanism” is required and allowed values for the element are 
“embedded” or “referenced”. See Figures 3, 4, and 5 below for examples. 

■ Developer Guidance: Mandatory. The value used, “embedded” or “referenced” will 
be determined by the convention that is acceptable to the downstream consumer. 

■ Rationale: At this point in time, TAO is sending data wrapped with the TDIW to 
different consumers using different locator conventions. For some consumers all of 
the data items are embedded. For others all of the data items are referenced. And for 
still others, all data items are addressed by a combination of embedded and 
referenced. 

■ PRESSUREWAVE Convention: This information best belongs in the proposed ‘how 
to use the TDIW’ document, but is listed here until that document is written. MMED 
wants to stay consistent with the convention employed by TURBINE. TURBINE 
embeds all its acquired data items, except for GetFile payloads. For the results of 
GetFile commands, TURBINE currently embeds the metadata that is extracted from 
the DNT Payload and uses the PRESSUREWAVE attributes to reference the actual 
DNT Payload. The convention for publishing GetFile results to PRESSUREWAVE 
will be: 

■ Extract the XML metadata contained in the DNT payload and embed that XML 
in a Dataltem element within the TDIW. Use the Locator mechanism of 
“embedded”. 

■ Publish the acquired file contained in the DNT payload as a separate object to 
PRESSUREWAVE. 

■ Document the URI for the separate object in a second Dataltem element in the 
same TDIW. Use the Locator mechanism of “referenced”. 
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Figure 3. TDIW with embedded data. 
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2.4.4.7 (U) Payload 

(U) This element provides specific information for the payload. Based on the determined 
value for “Locator”, the payload details may be contained in this element, or this 
element will just include the referenced location or file name. Two options exist for 
delimiting the embedded information: “Payload” or “XmlPayload”. When: “Payload” 
is used, the encoding type should be specified. The values for entry are “TEXT”, 
“BINHEX”, and “URI”. 

■ Developer Guidance: Mandatory. 

■ Rationale: To stay consistent with current TURBINE implementation. 

■ PRESSUREWAVE Convention: This information best belongs in the proposed 
‘how to use the TDIW’ document, but is listed here until that document is written. 

■ Use XmlPayload for embedded data that is completely XML. E.g.,: 

■ <XmlPayload>XML copied to here</XmlPayload> 

■ Use payload for embedded data this is not completely XML. E.g.,: 

■ <Payload encodingType=“TEXT/BINHEX”>payload copied 
here</Payload> 

■ Use payload for embedded data this is the reference URI. E.g.,: 

■ <Payload encodingType=“URI”>URI copied here</Payload> 


2.4.4. 8 (U) Task Execution Status 

(U) The “TaskExecutionStatus” describes the status of the specific implant command. 
Allowable values are “Success”, “Failure”, “Unknown”, and “Partial”. 

■ Developer Guidance: Mandatory if known. 

■ Rationale: enables down stream processing to make sense of acquired data item 
especially if it is suspected to be incomplete or corrupted. 
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(U//FOUO) FAQ’s 

Ql) Regardless of when “CreatedDateTime” element goes into operations, is this 
element relevant to age-off? 

Al) The “CreatedDateTime” element is explicitly relevant to age -off. Purge Surge 
efforts were emphatic that age-off must be based on the date/time of intercept, not on 
date/time of storage (which many systems had implemented.) and that date time 
information must accompany the data. The label "CreatedDateTime" was specified 
by TE2 vice DTOI, since many data objects that NSA will need to age off will not 
have been intercepted. “CreatedDateTime” is a more generically applicable label. 

Q2) Would it not be the 'beginDateTime' and/or the 'duration' elements of the 
activity Authorization? 

A2) “beginDateTime” is rarely used with the Retain activity. Retention is usually 
defined as a duration based on some trigger event, normally acquisition. So to 
properly calculate the age-off date, you need the retention duration and the 
CreatedDateTime. 

Q3) So when is the activity Authorization xsd going to be pulled into the tdiw? 

A3) The activityAuthorization xsd is already a core component of the TDIW. 

Q4) Do our customers know the semantics/meaning of the tdiw elements (e.g. 
“CreatedDateTime”, etc..), is this documented anywhere? 

A4) Most of our customers have a fair understanding of the semantics of the elements 
in the TDIW. “CreatedDateTime” was added to address a need raised by 
TURBINE. The XSD contains some annotations. There is information available, in 
addition to this document that can provide further guidance. 

Q5) Why are some of the elements optional? 

A5) The TDIW was originally intended to accompany Data Items. In that 
usage, elements such as “CreatedDateTime” would be mandatory. 
“CreatedDateTime”, for example, is a recent enhancement to the TDIW XSD to 
support TURBINE. TURBINE is populating the element. MMED is not populating 
the element yet. MMED has used the TDIW for more than what it was originally 
intended. It is those other uses of the TDIW that have forced us to make some 
elements optional, when they should be mandatory. Those are issues that should be 
resolved as we move forward with enhancements to our Security Marking Service 
and Data Marking Services. 

Q6) How do you document temporal values? 

A6) The temporal values for an activity can be expressed in any number of ways such 
as: explicit start and stop values, explicit start and duration, and trigger event and 
duration. If we are documenting an activity, we need to document the appropriate 
temporal values. The method for documenting the temporal values for an activity 
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will depend upon the activity. We have some rules already implemented via the 
MM A. 
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(U//FOUO) Appendix A - Sample Populated TDIW 

(U//FOUO) A sample will be included in a subsequent version of the TDIW 
documentation. 
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(U//FOUO) Appendix B - TDIW SCHEMA 

(U//FOUO) The schemas for the TDIW can be found on the TAO/MIT web site: “go 
mit”, or http://www.sigint.nsa/sublevell/si3/si32/si325/index.html , in the Additional 
In formation Section, listed under TAO Enterprise Services, TAO Security Marking 
Service. 
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(U) Coming Attractions 

This document describes TDIW version 2.3. As the TDIW continues to grow, 
changes will be recommended and implemented in subsequent versions. Current 
reco mm endations for TDIW 2.4 are: 

1. Implementation of TD Enterprise Security Model (ESM) 1.3 

2. Modification of the retention rules in the Data Item section. Based on guidance 
from TAO/R&T and TAO Compliance personnel, 5 years is the default retention 
for EO 12333 collect. The current TDIW versions provides the ability to list the 
retain activity as "indefinite". The rule will be changed to comply with the 5 year 
duration rule. Collection activity with "indefinite" as an expiration value is 
correct because EO 12333 does not have an expiration date. EO 12333 will 
remain in effect until super ceded. 

3. Many of the facts currently documented in the Authorization Model’s 
DataHandlingRequirement element, such as LegalAuthorityFramework, and 
RAGTIME markings will be addressed in ESM 1.3 under AccessControls 
attribute “MAF” (Mission Authorization Framework) and LAC (Legal Authority 
Category) respectively. The value for the MAF will change from RAWSIGINT 
to SIGINT. 
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(U) References 

(U//FOUO) This document is a good place to start looking for information on the 
elements of the TDIW and their definitions. However, the complete guide can be 
supplemented by a number of other documents. These documents are listed here for your 
convenience: 

• The Enterprise Data Model Security User’s Guide version 1 .3 

https://ccdm.eis.nsa/resources/products/documents/SecurityUsersGuide 1.3. 

pdf 

• The (TE2) Enterprise Data Modeling (EDM), Authorization Model 1.2 

https://wiki.itd.nsa/wiki/Authorization Data Model 

• CCDM_Traffic4.5.2Excerpts.xsd 

• oim_types/vl_0.xsd 

• DNI CAPCO: IC Classification and Control Markings Implementation Manual, 
Version 3.1, 7 May 2010 

• Authorized Classification and Control Markings Register, Version 3.1, 7 May 
2010 

• Common In formation Sharing Standard for Information Security Marking: XML 
Implementation, Implementation Guide, Release 2.0.3, Office of the Director of 
National 

• Intelligence Chief Information Officer, 15 February 2006 

• Common Information Sharing Standard for Information Security Marking: XML 
Implementation, Data Element Dictionary, Release 2.0.3, Office of the Director of 
National Intelligence Chief Information Officer, 15 February 2006 

• Intelligence Community Metadata Standards for Information Assurance - 
In formation Security Marking (Release 1.0, 5 July 2002), IC Metadata Working 
Group 

• Intelligence Information Sharing Standard for Information Security Marking: 
XML Implementation, Implementation Guide, Release 2.0.2, 15 February 2006 

• Second Party Marking and Labeling Policy, Security Planning and 
Implementation Group, 29 May 2001, URL: 
http://www.partners/spig/labeling/policy.html. 

• SPIG Guidance to ICWG for Data Labeling Version 1.0, dated 6 January 2004 at 
&lt;http://www.gchq/partners/spig/core_business/dptt/documents/spig_guidance.d 
oc&gt; 

• Intelligence Community Classification and Control Markings Implementation 
Manual, Annex A, Registered International Organizations and Alliances, 

Versions: 20070327 

• EO 12598 and Intelligence Information Sharing Standard for Information Security 
Marking Data Element Dictionary, Release 1.0, 15 November 2004 

• Registered International Organizations and Alliances, Volume 1, Edition 1 
(Version 1.1): 31 
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